In a client-server environment, a transaction based model is often used where a short-lived client request/server response occurs, and the server retains no state information about the client (referred to as a "stateless" server). Frequently, the client requires some context for subsequent transactions. In such cases, it is possible for state information to be stored by the client (referred to as a "stateful" client) and sent with subsequent requests to the server. Common examples of such a model are the Network File System (NFS) and Internet web clients/servers using the HTTP cookie extension to the HTTP protocol. A software token containing state information is exchanged between the client and server. It is typically created or set by the server when responding to a client request. The contents of the token are opaque to the client and interpretable only by the server. The client receives the token along with data in response to its request and will send the token back to the server on some subsequent request. Because of the asynchronous nature of such sequential transactions in a client-server environment, it is not known when or if the client will issue another request. Therefore, tokens typically have some expiration time or date after which the client will not send the token to the server, or the server will not accept the token, depending upon the particular client-server application.
In the case where the client decides whether the token has expired, token expiration information is not opaque to the client although token data is. This creates the potential for modification of the token expiration by a client. Even trusted client software can be made to continue to send a token which should have expired by modifying the client system clock when it is used in determining token expiration. The seriousness of such tampering depends upon the role of the token in the particular client-server application.
On most every client-server transaction between a stateless server and stateful client, a token is transmitted. The size of a token is usually a small percentage of the size of the data transferred on a given transaction. Token size should be minimized, however, because in high load environments where there are many clients frequently performing transactions with a single server, the system performance will improve when a small token is used.